Bu ne ile ilgili?
Manifest V2'den Manifest V3'e geçiş temel bir değişiklikle birlikte gelir. Manifest V2'de uzantılar bir arka plan sayfasında bulunuyordu. Uzantılar ile web sayfaları arasındaki iletişimi arka plan sayfaları yönetiyordu. Manifest V3, bunun yerine Service Worker'ları kullanır.
Bu gönderide, uzantı hizmeti çalışanlarını test etme sorununu ele alacağız. Özellikle, bir hizmet çalışanının askıya alınması durumunda ürünümüzün düzgün bir şekilde çalıştığından nasıl emin olacağımızı araştırıyoruz.
Biz kimiz?
eyeo; kullanıcılar, tarayıcılar, reklamverenler ve yayıncılar için dengeli ve sürdürülebilir bir online değer alışverişini desteklemeyi amaçlayan bir şirkettir. Bir reklamın kabul edilebilir olup olmadığını belirleyen bağımsız tür bir reklam standardı olan Kabul Edilebilir Reklamlar'ın gösterilmesine izin veren 300 milyondan fazla global reklam filtreleme kullanıcımız bulunmaktadır.
Extension Engine ekibimiz, dünya genelinde 110 milyondan fazla kullanıcıya sahip AdBlock ve Adblock Plus gibi piyasadaki en popüler reklam engelleme tarayıcı uzantılarından bazılarını destekleyen reklam filtreleme teknolojisi sağlar. Ayrıca bu teknolojiyi açık kaynak kitaplık olarak sunarak diğer reklam filtreleme tarayıcı uzantılarının kullanımına sunuyoruz.
Service Worker nedir?
Uzantı hizmeti çalışanları, bir tarayıcı uzantısının merkezi etkinlik işleyicisidir. Arka planda bağımsız olarak çalışırlar. Genel olarak bu soruna neden olmaz. Arka plan sayfasında yapmamız gereken işlemlerin çoğunu yeni Service Worker'da yapabiliyoruz. Ancak, arka plandaki sayfalara kıyasla birkaç değişiklik söz konusudur:
- Service Worker'lar kullanılmadığında sonlandırılır. Bu, genel değişkenlere güvenmek yerine uygulama durumlarını sürdürmemizi gerektirir. Diğer bir deyişle, sistemimize giren giriş noktaları, sistem başlatılmadan önce çağrılmaya hazırlanmalıdır.
- Zaman uyumsuz geri çağırmalar beklenmeden önce etkinlik işleyiciler eklenmelidir. Askıya alınan hizmet çalışanları, abone oldukları etkinlikleri almaya devam edebilir. Etkinlik dinleyicisi, etkinlik döngüsünün ilk sırasında kayıtlı değilse bu etkinlik Service Worker'ı uyandırdıysa etkinliği almaz.
- Boşta kalma sonlandırması, tamamlanmadan önce zamanlayıcıları kesintiye uğratabilir.
Service Worker'lar ne zaman askıya alınır?
Chrome 119'da hizmet çalışanlarının askıya alındığı tespit edildi:
- 30 saniye boyunca etkinlik veya uzantı API'leri çağrılmadığında.
- Geliştirici araçları açıksa veya ChromeDriver tabanlı bir test kitaplığı kullanıyorsanız hiçbir zaman kullanmayın (özellik isteğine bakın).
- chrome://serviceworker-internals sayfasında Durdur'u tıklarsanız.
Daha güncel bilgiler için Hizmet Çalışanlarının Yaşam Döngüsü sayfasına bakın.
Bu test neden bir sorun teşkil ediyor?
İdeal olarak, "hizmet çalışanlarının verimli bir şekilde nasıl test edileceği" konusunda resmi bir rehber veya çalışma testi örnekleri olması yararlı olur. Hizmet çalışanlarını test etme maceramız sırasında birkaç zorlukla karşılaştık:
- Test uzantımızda durumu mevcuttur. Hizmet çalışanı durduğunda durumunu ve kayıtlı etkinliklerini kaybederiz. Test akışımızdaki verilerin kalıcı olmasını nasıl sağlayabiliriz?
- Service Worker'lar herhangi bir noktada askıya alınabiliyorsa, kesintiye uğrayan tüm özelliklerin çalışıp çalışmadığını test etmemiz gerekir.
- Testlerimizde Service Worker'ları rastgele askıya alan bir mekanizma eklesek bile, tarayıcıda bunu kolayca askıya alabilecek bir API yoktur. W3C ekibinden bu özelliği eklemesini istedik, ancak bu konu devam ediyor.
Test Hizmet Çalışanının Askıya Alınması
Testler sırasında Service Worker'ların askıya alınmasını tetiklemek için çeşitli yaklaşımlar denedik:
| Yaklaşım | Yaklaşımla ilgili sorunlar |
| Rastgele bir süre bekleyin (örneğin 30 saniye) | Bu, özellikle birden fazla test çalıştırılırken testi yavaşlatır ve güvenilmez hale getirir. WebDriver, Chrome'un DevTools API'sini kullandığından ve Geliştirici Araçları açıkken hizmet çalışanı askıya alınmadığından WebDriver kullanılırken çalışmaz. Bunu atlatabilsek bile, hizmet çalışanının askıya alınıp alınmadığını kontrol etmemiz gerekecekti ve bunu yapabileceğimiz bir yol olmayacaktı. |
| Service Worker'da sonsuz döngü çalıştırma | Bu özellik, spesifikasyona göre tarayıcının bu işlevi nasıl uyguladığına bağlı olarak sonlandırmaya yol açabilir. Bu durumda Chrome, Service Worker'ı sonlandırmaz. Bu nedenle, hizmet çalışanı askıya alındığında senaryoyu test edemeyiz. |
| Service Worker'da, askıya alınıp alınmadığını kontrol eden bir mesaj | Mesaj gönderildiğinde Service Worker uyandırılır. Bu, hizmet çalışanının uykuda olup olmadığını kontrol etmek için kullanılabilir ancak hizmet çalışanı askıya alındıktan hemen sonra kontrol yapması gereken testlerin sonuçlarını kesintiye uğratır. |
| chrome.processes.terminate() kullanarak Service Worker işlemini sonlandırın | Uzantının hizmet çalışanı, uzantının diğer bölümleriyle bir işlemi paylaştığından chrome.process.terminate() veya Chrome'un işlem yöneticisi GUI'si kullanılarak bu işlemin sonlandırılması, yalnızca hizmet çalışanının değil, uzantı sayfalarının da sonlandırılmasına neden olur. |
Sonunda, Selenium WebDriver'ı chrome://serviceworker-internals/ açıklayıp Service Worker için "dur" düğmesini tıklayarak kodumuzun, askıya alınan hizmet çalışanına nasıl yanıt verdiğini kontrol eden bir test yaptık.
Bu şu ana kadar en iyi seçenektir, ancak Mocha testlerimiz (bir uzantı sayfasında çalıştırılır) bunu kendi başına yapamadığından, WebDriver düğüm programımızla iletişim kurmaları gerektiğinden ideal değildir. Diğer bir deyişle, bu testler yalnızca uzantı kullanılarak çalıştırılamaz; Selenium WebDriver kullanılarak tetiklenmeleri gerekir.
Aşağıda, farklı akışlar üzerinden tarayıcı API'si ile nasıl iletişim kurduğumuzu ve "hizmet çalışanlarını askıya alma" mekanizmasının eklemenin bunu nasıl etkilediğini görebilirsiniz.
Service Worker'ları (mavi) askıya alan yeni bir akışta, Selenium WebDriver'ı kullanıcı arayüzü üzerinden "tıkla" askıya alma işlevi için ekledik. Bu işlem, tarayıcı API'sinde bir işlemi tetikler.
Bu işlemi Selenium WebDriver ile yaparken Service Worker'ın tekrar başlatılamamasına yol açan bir Chrome hatası vardı. Bu sorun Chrome 116'da düzeltildi. Neyse ki bir geçici çözüm de var: Chrome'un her sekmede Geliştirici Araçları'nı otomatik olarak açacak şekilde ayarlanması, hizmet çalışanının doğru şekilde başlamasını sağlar.
Düğmenin tıklanması kararlı bir API olmayabileceği ve DevTools'un (eski tarayıcılar için) açılması performans maliyetinin olduğu görüldüğünden ideal olmasa da, test sırasında bu yaklaşımı kullanıyoruz.
Tüm işlevi nasıl ele alabiliriz? Fuzz Testleri
Askıya alma testi için bir mekanizmamız olduğunda bunu otomasyon test paketlerimize nasıl bağlayacağımıza karar vermemiz gerekiyordu. Standart testlerimizi, arka plan sayfasıyla her etkileşimden önce chrome://serviceworker-internals/ sayfasında Durdur'u tıklayan WebDriver tarafından hizmet çalışanı askıya alınan bir ortamda gerçekleştirdik.
Süspansiyon mekanizması tam olarak stabil olmadığı ve bazen gevşekliğe neden olduğu için testlerin çoğunu değil, çoğunu yapıyoruz. Ayrıca, tüm test paketlerini fuzz modunda çalıştırmak çok zaman alıyor. Dolayısıyla, tüm "benzer" durumları kapsamak yerine, fuzz modunda test yapmak için en kritik yolları seçtik. İşlevsel testleri "fuzz" modunda çalıştırmanın, hizmet çalışanlarının askıya alınması ve yeniden başlatılması daha fazla zaman aldığından test zaman aşımlarını artırmamız gerektiği anlamına gelir.
Bu testler, kodun başarısız olduğu birçok yeri vurgulayan genel bir ilk geçiş olarak değerlidir ancak hizmet çalışanı askıya alma işleminin, sorunların ortaya çıkmasına neden olabileceği göze çarpmayan tüm yolları ortaya çıkarmayabilir.
Şirket içinde bu tür testlere "Fuzz testleri" diyoruz. Geleneksel olarak fuzz testi, programınıza geçersiz giriş atıp makul bir yanıt verdiğinden veya en azından çökmediğinden emin olmak için yapılır. Örneğimizde "geçersiz giriş", herhangi bir zamanda askıya alınan hizmet çalışanıdır. Reklam filtreleme işlevimizin ise eskisi gibi çalışmaya devam etmesini beklediğimiz "makul davranış" budur. Bu, Manifest V3'te beklenen bir davranış olduğu için gerçekten geçersiz bir giriş değildir. Ancak Manifest V2'de geçersiz olacağı için makul bir terminoloji gibi görünüyor.
Özet
Service Worker'lar, Manifest V3'teki en büyük değişikliklerden biridir (declarativeNetRequest kurallarının yanı sıra). Manifest V3'e taşıma işlemi, tarayıcı uzantılarında birçok kod değişikliği yapılmasını ve yeni test yaklaşımlarının kullanılmasını gerektirebilir. Ayrıca, kalıcı duruma sahip uzantı geliştiricilerinin, uzantılarını beklenmedik hizmet çalışanı askıya alma işlemini sorunsuz bir şekilde ele alacak şekilde hazırlamaları gerekir.
Maalesef, askıya alma işlemini kullanım alanımıza uygun, kolay bir şekilde ele alabilecek bir API mevcut değil. İlk aşamada, uzantımızın kod tabanının askıya alma mekanizmalarına karşı ne kadar sağlam olduğunu test etmek istediğimiz için bu soruna bir çözüm bulmamız gerekti. Benzer zorluklarla karşılaşan diğer uzantı geliştiricileri bu geçici çözümü kullanabilir. Geliştirme ve bakım aşamasında zaman alıcı olsa da, uzantılarımızın hizmet çalışanlarının düzenli olarak askıya alındığı bir ortamda başarılı bir şekilde çalışabilmesini sağlamak için buna değer.
Service Worker askıya alma testi için temel destek mevcut olsa da, gelecekte uzantılar üzerinden hizmet çalışanlarını test etmek için daha iyi platform desteği sunmak, test yürütme sürelerimizi ve bakım çabalarımızı önemli ölçüde azaltabileceğinden, ileride görmek istediğimiz bir şey.